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interpretation of a destination device profile to convert coordinates in a destination device color 
space to the device-independent color space, in combination with generation of a color map 
based on the converted coordinates and user preferences that are specified by a u$er 
independentiy of the source and destination device profiles. As examples of user preferences^ 
dependent claims 26 and 27 recite illuminant functions and observer functions, respectively. 

Applicants respectfully submit that the Examiner has misinterpreted the scope and 
content of the McGreggor et al. reference relative to the requirements of the claimed invention. 
In formulating the rejection, the Examiner incorrectiy relied in large part on the features of FIG. 
14 of McGreggor et al. FIG. 14 has nothing to do ^vith the generation of a color map between a 
source device and a destination device. In particular, FIG. 14 does not pertain to the 
interpretation of source and destination device profiles, or the generation of color maps. Rather, 
FIG, 14 depicts a "transfer mode" architecture. 

The transfer mode architecture described by McGreggor et al. is completely unrelated to 

the color mapping features recited in Applicants' claims. Indeed, the description of FIG. 14 in 

McGreggor et al, falls under the heading '*in. Color Combining," unlike FIG. 1 5 wrhich falls 

under tiie heading "TV. Color Matching-" See Col 13, line 65 and CoL 18, line 40, According to 

McGreggor et al., the term '^transfer mode" refers to a process for combining color$ in an image. 

For example, McGreggor et al. states that: 

In the preferred system, color combinations are carried out in a recursive transfer 
mode, where an input color is transferred over a destination color, to generate a 
new destination color . , , Transfer modes specify how the color drawn interacts 
with the background color. 

Col, 13, line 67, to CoL 14, line 3. McGreggor et al. describes a number of alternative transfer 

modes such as a "copyMode " in which the "source component replaces the destination 

component," an "addMode," in which the "source component is added to the destination 

componentj but does not allow the result to exceed some maximum/' a "blendMode," in which 

the "destination component is replaced by the average of the source component and destination 

component, using the operand component to specify the ratio,'' and many other transfer modes. 

Essentially, a transfer mode concerns the drawing of color from a source object onto a 

destination object to form a new destination object or ^tesult," that combines both colors. The 
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following diagram, taken from Apple Computer Quicktime documentation , should aid in 
visualization of the effects of a typical, tracusfer mode operation in which a "Source" object is 
combined with a "Destination" object to form a composite "Result." 
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Consistent with tlie above diagram, McGreggor et aL explains that: 

the [disclosed] system is provided with more than one input source colors [sic], 
and the operator operates on a combination of the input source colors. The input 
source colors may have the same or different color spaces. This also provides the 
ability to perform transfer operations in which a source color is combined witli a 
destination color to generate a new destination color. This corresponds to taking 
an image already being displayed on the screen and overwriting it with a new 
image^ in a manner which does not completely destroy the data specifying the 
original image. 

(emphasis added) CoL 2, lines 34-44. 

Hence, it is clear that the "transfer mode" features of FIG. 14 of McGreggor et al. is of no 
relevance to the color map requirements of Applicants' claims. Ratherp it appears that the 
Examiner may have been conftised by the mention of "source" and "destination" components in 
FIG, 14, and presumed some relationship to source and destination profiles, as set forth in the 
claims. Upon recognition of the true scope and content of FIG. 14 of McGreggor et al., it will be 
apparent that the rejections under section 103 are improper and should be withdrawn. 

The Examiner's reliance on FIG. 15 of McGreggor et ah is also misplaced. FIG. 15, 
unlike FIG. 14, actually relates to color matching and the use of source and destination device 
profiles. However, FIG. 1 5 suggests nothing more than the conventional and ordinary usage of 
such profiles in forming a color map. For example. FIG. 15 and tlie accompanying description in 

^ http;//develQper.appkxom/techpub5/quicldimc/qtdevdocs/REF 
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McGreggor et al, provide no teaching that woiild have suggested generation of a color map based 
on the converted coordinates and user preferences that are specified by a nser independently of 
the source and destination device profiles, as set forth in the claims. Therefore, FIG. 15 adds no 
teachings sufficient to cure the deficiencies apparent in FIG, 14 of McGreggor et al., as discussed 
above. Therefore, the rejections under section 103 should be withdrawn. 

Also, the Examiner's reference to user input device 221 01 in FIG. 22 falls far short of any 
teaching that would have suggested generati on of a color map based on converted coordinates 
and user preferences that are specified by a user independently of source and destination device 
profiles, as set forth in the claims. McGreggor et al. simply makes no mention of the 
specification of user preferences by a user via user input device 22101. Instead, McGreggor et al. 
merely notes that the disclosed system may have a keyboard. Col. 21, lines 41-46. Again, in 
view of this deficiency, the rejections under section 1 03 should be withdrawn. 

Finally, the Examiner's reference to the user's ability to alter tlie luminance of an input 
color in McGreggor et al, is misplaced. Tlie Examiner asserted that this feature corresponds to 
the selection of user preferences in the form of illuminant conditions. At Col. 33, lines 38-60, 
however, McGreggor et al. describes manipulation of input colors within a working color space. 
The alteration of luminance concerns the adjustment of the input color values, and not the 
specification of user preferences such as illuminant conditions. 

It is important to understand that luminance and illuminant conditions are two entirely 
different things. Luminance, as used in McGreggor et al., refers to a value on one of the 
coordinate axes of the HLS (hue, luminance, saturation) color space, Illuminant conditions refer 
to viewing conditions for an image, i.e., tlie lighting under which a particular image is viewed by 
a human observer. An exemplary illuminant condition is D50. With this further 
misunderstanding, the rejections under section 103 should be withdrawn. 

In view of the fundamental deficiencies clearly evident in McGreggor et al.. Applicants 
respectfiilly reserve any comment concerning the teachings of Berlin et al, and Schwartz et al. 
Clearly, such references provide no teachings sufficient to bridge the gap between McGreggor et 
al. and the claimed invention. 
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Rejection for Obviousness-type Double Patenting 

The Examiner also rejected claims 25, 32-33, 38 and 41 under the judicially created 
doctrine of obviousness-type double patenting as being unpatentable over claims 1, 10, 13, 18, 
37, 41, 45-47 of commonly owned U.S* Patent No. 6,088,038. Applicants respectfully traverse 
this rejection. 

Applicants respectfully submit that the Examiner has not established a prima facie case of 
obviousness-type double patenting. To support an obviousness-type double patenting rejection, 
the Exanoiiner must asse$s the differences between the claims in the pending application and the 
claims in the issued patent InreBej^ . 46 USPQ2d 1226, 1229 (Fed Cir. 1998), In particular, 
the Examiner should indicate why the claims in an application are obvious over the claims in the 
granted patent. Id. 

In the Office Action, the Examiner merely stated that the application and patent claims 
are not patentably distinct ^'because claimed feature is just broadly claimed," The proper analysis 
is not whether features are broadly claimed, but whether such features would have been obvious 
in view of the claims set forth in the issued patent. Applicants respectfiilly submit that the 
pending claims, which relate to generation of a color map, would not have been obvious in view 
of the patent claims, which generally relate to retrieval, application and use of color maps and 
device links. 

The rejection for obviousness-type double patenting should be withdrawn. If the 
Examiner chooses to maintain tlie obviousness-type double patenting rejection, however, 
Applicants respectfully request clarification of the grounds of rejection. 
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ALL claims in this application are in condition for allowance. Applicants respectfully 
request reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1 778. 

Date: By: 




SHUMAKER & SIEFFERT, P.A. Name: Steveftl. Shumaker 

8425 Seasons Parkway, Suite 105 Reg. No.: 36,275 

St. Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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